When organizations need to have large-scale computer systems that hold mission critical information, such as purchase orders, financial information, etc., they usually resort to message transaction systems. Message transaction systems ensure that data is not lost if the system crashes, and also that data is not duplicated—such as ensuring that two copies of the same purchase order are not processed, etc. A transaction is an activity or a request, such as an order, a purchase, a change, or an addition to a database of information. Transactions usually update one or more files on a non-volatile storage such as a hard disk drive, and thus can serve as both an audit trail and a history for future analyses. A transaction can include one or more messages. A transaction is considered committed when all the messages of the transaction have been received and processed.
Frequently, messages are desired to be used to trigger specific functionality, which can be found in modules, which include but are not limited to software components, such as ActiveX components, Java Beans, Component Object Model (COM) components, etc., as known within the art, as well as executable program files—program files ending in .exe, for example. Within the prior art, for messages to trigger a module, an application has to be developed that opens a message queue in which messages are received, process the messages to check for messages that are desired to trigger the module, and then trigger the module if such messages are found, and dispatch the messages as necessary. However, this is disadvantageous, because to add new functionality triggering, new applications have to be developed, or existing applications have to be redeveloped. This can be expensive, from a time and cost perspective. For this and other reasons, therefore, there is a need for the present invention.